feat: add resolving-github-issues skill#137
Conversation
Systematic workflow for analyzing and implementing fixes for GitHub issues: - Phase-based approach: Fetch → Analyze → Plan → Checkpoint → Implement - Feasibility assessment with complexity rating - Three determination paths: proceed, clarify, or beyond scope - User checkpoint before implementation (never auto-commit) - Safety measures and common mistakes documented 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
WalkthroughAdds a new Markdown skill document at Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
skills/resolving-github-issues/SKILL.md (2)
68-68: Add language specifiers to fenced code blocks. Lines 68, 82, and 89 contain template code blocks without language identifiers. These should specify a language (e.g.,```textor```diff) to comply with Markdown best practices.Apply this diff to add language specifiers:
- ``` + ```text IMPLEMENTATION PLAN- ``` + ```text REQUIRES CLARIFICATION- ``` + ```text COMPLEXITY WARNINGAlso applies to: 82-82, 89-89
139-156: Use heading syntax for Common Mistakes subsections instead of bold emphasis. Lines 141, 145, 149, and 153 use**bold**formatting for section headers within the Common Mistakes section. Markdown convention and linting rules recommend using heading syntax (e.g.,### Starting implementation without checkpoint) for better semantic structure and accessibility.Apply this diff to convert emphasis to headings:
- **Starting implementation without checkpoint** + ### Starting implementation without checkpoint - **Skipping codebase analysis** + ### Skipping codebase analysis - **Underestimating complexity** + ### Underestimating complexity - **Auto-committing or pushing** + ### Auto-committing or pushing
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
skills/resolving-github-issues/SKILL.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
skills/resolving-github-issues/SKILL.md
[style] ~101-~101: Consider using a more formal alternative.
Context: ...tinue?" - REQUIRES CLARIFICATION: "Need more info. Want me to comment on the issue?" - BE...
(MORE_INFO)
🪛 markdownlint-cli2 (0.18.1)
skills/resolving-github-issues/SKILL.md
68-68: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
82-82: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
89-89: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
141-141: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
145-145: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
149-149: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
153-153: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
🔇 Additional comments (4)
skills/resolving-github-issues/SKILL.md (4)
1-14: Well-structured frontmatter and clear introduction. The description starts with "Use when..." as required and comprehensively summarizes the skill's purpose. The core principle (Fetch → Analyze → Plan → Checkpoint → Implement → Verify) is well articulated, and the "announce at start" instruction sets appropriate context.
29-126: Comprehensive, logical workflow with seven clearly defined phases. Each phase has specific actionable steps (e.g.,gh issue view, git commands), clear outputs, and decision criteria. The progression from Fetch → Analyze → Assess → Determine → Checkpoint → Implement → Complete is well-reasoned and prevents premature implementation.
96-169: User control and safety measures are explicit and well-enforced. Phase 5 mandates approval before proceeding; Phase 7 offers options rather than auto-proceeding; the Safety Measures section explicitly prohibits auto-commit/push (lines 160, 163). The repeated emphasis on checkpoints and approval aligns perfectly with the PR requirement that "the skill never auto-commits."
171-176: Integration references are clear and contextually appropriate. The skill correctly identifies complementary workflows (finishing-a-development-branch, systematic-debugging) and notes the creating-github-issues skill as the inverse workflow. Verify that the referenced skills exist in the codebase by confirming their SKILL.md files are present in the skills directory.
- Add language specifiers (text) to fenced code blocks (lines 68, 82, 89) - Convert bold text to proper ### headings in Common Mistakes section 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
skills/resolving-github-issues/SKILL.md (1)
98-102: Minor: Inconsistent formality in checkpoint prompts.Line 100 uses the more formal "Shall I continue?" while lines 101–102 use the informal "Want me to..." Consider standardizing to maintain consistent tone:
- REQUIRES CLARIFICATION: "Need more info. Want me to comment on the issue?" + REQUIRES CLARIFICATION: "Need more info. Should I comment on the issue?" - BEYOND SCOPE: "This needs [X]. Want me to document findings on issue?" + BEYOND SCOPE: "This needs [X]. Should I document findings on the issue?"This aligns with the formal "Shall I..." on line 100 and improves the professional tone during user interactions.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
skills/resolving-github-issues/SKILL.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
skills/resolving-github-issues/SKILL.md
[style] ~101-~101: Consider using a more formal alternative.
Context: ...tinue?" - REQUIRES CLARIFICATION: "Need more info. Want me to comment on the issue?" - BE...
(MORE_INFO)
🔇 Additional comments (7)
skills/resolving-github-issues/SKILL.md (7)
1-4: Well-formatted front matter and clear trigger description.The metadata and description effectively communicate the skill's purpose and when to invoke it. The "Use when..." trigger phrasing is appropriate for a skill document.
6-25: Clear overview with well-defined usage scope.The "When to Use" and "Don't use for" sections prevent scope creep and clearly delineate this skill from related workflows. The announcement guidance is a nice touch for transparency.
27-126: Comprehensive and logically sound phase workflow.The seven-phase structure effectively separates information gathering, decision-making, and execution. The placement of the user checkpoint (Phase 5) before implementation is a strong control point that prevents wasted effort and maintains user agency. The feasibility assessment table is practical and covers key risk dimensions.
127-137: Excellent quick reference table.The table effectively summarizes all seven phases with clear phase names, actions, and outputs. Useful for quick review and as a mental model reminder.
139-155: Well-chosen common mistakes with practical fixes.Each mistake directly reinforces a key safety principle (checkpoint enforcement, thorough analysis, conservative complexity ratings, no auto-commit). The structure of problem → fix is clear and actionable.
157-169: Comprehensive safety measures aligned with workflow phases.The "Never" and "Always" sections effectively reinforce the core principles: user control (no auto-commits, checkpoints), change safety (testing, diffs), and destructive action prevention (force-push restrictions). These directly support the skill's goal of user-centric issue resolution.
171-175: Clear skill integrations with appropriate cross-references.The integration section effectively identifies downstream workflows (
finishing-a-development-branch), conditional-use scenarios (systematic-debuggingfor complex bugs), and complementary opposites (creating-github-issues). This helps users understand how the skill fits into the broader ecosystem.
|
Hi! Claude, in my experience, has no problem resolving github issues. Can you tell me about the problems that led to this skill and your other github-related skill? |
|
It doesn’t evaluate whether the issue is complete and actionable and it
doesn’t always start working in a feature branch. I’ve been using this
skill for a while and it produces superior results.
Regards,
…--Paul
Quality is never an accident; it is always the result of high intention,
sincere effort, intelligent direction, and skillful execution. --William
A. Foster
Paul Holstein
954-536-6678 | www.linkedin.com/in/paulholstein/
***@***.*** | Fort Lauderdale, FL - Asheville, NC
<https://maps.google.com/?q=43+E+Chestnut+St,+Asheville,+NC+28801>
[image: facebook] <https://facebook.com/paulh> [image: linkedin]
<https://us.linkedin.com/in/paulholstein>
On Tue, Dec 2, 2025 at 6:20 PM Jesse Vincent ***@***.***> wrote:
*obra* left a comment (obra/superpowers#137)
<#137 (comment)>
Hi! Claude, in my experience, has no problem resolving github issues. Can
you tell me about the problems that led to this skill and your other
github-related skill?
—
Reply to this email directly, view it on GitHub
<#137 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKRWOAJ3KDNCRZTGHJNA4OT37YNDZAVCNFSM6AAAAACNZ3AX42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMBUGM2TMMRQGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Thanks for the thought you put into this! After review, we think this workflow is largely covered by existing skills:
The formal phases and templates add structure, but we're trying to keep superpowers focused on skills that change behavior rather than document natural workflows. Appreciate the contribution! — Claude (in consultation with Jesse) |
2 participants
Summary
Change Type
feat:- New feature (MINOR: x.X.0)Breaking Changes
N/A
Test Plan
Context
This skill fills a gap in the superpowers collection - there's currently no workflow for handling GitHub issues. This provides a structured approach that:
finishing-a-development-branchandsystematic-debuggingThe complementary skill
creating-github-issues(for the opposite workflow) will be submitted as a separate PR.🤖 Generated with Claude Code
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.